寫在前面：
這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security 的朋友交流。
CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission 後續 Guidance、Harmonised Standards 及主管機關實務為準。

Day 10 談完 Article 14，我又遇到另一個很容易混在一起的問題
上一篇談的是 Regulatory Reporting（法規通報），也就是符合 CRA Article 14 條件時，Manufacturer 需要依規定向 EU 相關機制進行 24 小時 Early Warning、72 小時 Vulnerability Notification，以及後續 Final Report。
但 Product 發現 Vulnerability 之後，其實還有另一條很重要的線，就是 Vulnerability Disclosure（漏洞揭露）。
例如 Security Researcher 發現漏洞，要怎麼通知我們？Manufacturer 收到後要不要公開？什麼時候告訴 Customer？要不要申請 CVE？如果需要公告，又應該在修補前還是修補後？
我一開始很容易把 Article 14 Reporting、CVD、Security Advisory、CVE 全部放在同一件事情裡。後來研究得越多，才慢慢覺得：它們彼此高度相關，但其實解決的是不同問題。

一、先從 CVD 開始：Coordinated Vulnerability Disclosure
CVD 是 Coordinated Vulnerability Disclosure（協調式漏洞揭露）。
CRA Annex I Part II 對 Manufacturer 的 Vulnerability Handling Requirements 中，要求建立並執行 Coordinated Vulnerability Disclosure Policy，同時採取措施促進產品及其中 Third-party Components 潛在 Vulnerability 資訊的分享，包括提供可以聯繫 Manufacturer 的 Vulnerability Reporting Contact Address。
所以對我而言，CVD 第一個核心其實不是「公告漏洞」，而是：
建立一個讓外部發現者可以安全、有效地把 Vulnerability 告訴 Manufacturer，而且 Manufacturer 有能力接住並處理的機制。
這兩件事情缺一不可。如果公司公布了一個 Security Contact，但信件寄進去之後沒有人負責、沒有 Case Management、沒有 Product Owner，也沒有後續追蹤，那其實只有「信箱」，還稱不上真正的 CVD Capability。

二、為什麼叫做「Coordinated」？
假設今天 Security Researcher 發現一個嚴重的 Remote Code Execution Vulnerability，如果隔天就把完整 Technical Details，甚至 Exploit Method 公開，Manufacturer 可能還來不及修補，Customer 也還沒有 Patch 或 Mitigation 可以使用，反而可能讓 Malicious Actor 更早取得可利用資訊。
所以我自己會把 CVD 理解成一個協調的過程：Researcher 發現 Vulnerability 後先通知 Manufacturer，Manufacturer 進行確認與分析，再開發 Fix 或 Mitigation，等相關保護措施準備到一定程度後，雙方再協調適當的 Disclosure Timing，最後才進行 Public Disclosure。
CRA Recital 76 也談到類似概念，CVD Policy 應提供一個 Structured Process，讓 Manufacturer 有機會在詳細 Vulnerability Information 被揭露給第三方或公眾之前，先進行 Diagnosis 與 Remediation。
這也是我目前對 Coordinated 這個字最直覺的理解：重點不只是 Disclosure，而是 Disclosure 前面的 Coordination。

三、所以第一步可能不是先寫一份很厚的 Policy
如果今天讓我從零開始建立 CVD Capability，我第一個想確認的問題反而很簡單：
外面發現我們產品有漏洞的人，找不找得到我們？
CRA Article 13 對 Manufacturer 的義務中，也要求指定 Single Point of Contact（單一聯絡窗口），讓 User 可以直接且快速地與 Manufacturer 溝通，包括 Product Vulnerability Reporting，而且這個聯絡方式應該容易被 User 找到，也不能只限制使用 Automated Tools 進行溝通。
因此，一個 Security Contact Email 或 Vulnerability Reporting Web Page 看起來非常基本，但我覺得這其實是 CVD 能不能真正運作的第一關。
因為對 Security Researcher 來說，他可能根本不知道你公司的 Product Security Team、Legal、Customer Support 或 R&D 在哪裡。他需要的第一件事不是看你的組織圖，而是知道：
「我發現你們產品可能有漏洞，我到底要通知誰？」

四、而且 CVD Policy 要讓 User 找得到
CRA Annex II 對提供給 User 的 Information and Instructions 也有相關要求，其中包括 Product Vulnerability 可以透過哪一個 Single Point of Contact 進行 Report / Receive，以及 Manufacturer 的 Coordinated Vulnerability Disclosure Policy 可以在哪裡找到。
因此，我自己會傾向不要只把 CVD Policy 寫成一份公司內部 SOP，然後放在內部文件管理系統裡。
內部當然還是需要比較完整的處理程序，例如誰負責收件、誰做 Triage、誰找 Product Team、誰決定 Severity、誰跟 Researcher 溝通，以及什麼情況需要 Escalation；但對外可能還需要一個 External-facing Version，讓 Researcher、Customer 與 User 知道怎麼跟我們合作。
對我而言，這兩份文件的 Audience 本來就不太一樣。

五、那 CVD Policy 裡可以寫什麼？
CRA 並不是直接附上一份 CVD Template，要求所有 Manufacturer 完全照抄。如果從實務角度思考，我自己可能會先放入 Vulnerability Reporting Channel、希望 Reporter 提供哪些資訊、Manufacturer 如何 Acknowledge、後續 Communication Method、Disclosure Coordination、Confidentiality Expectation，以及 Safe Research Expectation 等內容。
如果公司本來就有 Bug Bounty Program，也可以思考它跟 CVD 的關係。CRA Recital 76 也提到 Manufacturer 可以考慮 Bug Bounty Program，透過 Recognition 或 Compensation 鼓勵 Vulnerability Reporting。
不過這裡我會特別區分：Bug Bounty 並不是我目前理解的 CRA 必要條件，CVD 才是 CRA 要求的核心機制。
換句話說，公司不一定要付獎金給發現漏洞的人，但至少要建立一個可以讓 Vulnerability 被合理接收、處理與協調揭露的機制。

六、收到 Vulnerability 之後，也不是立刻公開
這一點我覺得很重要，因為 CVD 的精神本來就包含 Coordination。
Manufacturer 收到 Vulnerability Report 後，通常還需要進行 Validate、Reproduce、Identify Affected Products、Assess Impact、Develop Fix / Mitigation，以及 Verify Fix 等工作，接著才有條件判斷適當的 Disclosure Timing。
所以「收到 Vulnerability」和「立刻公告 Vulnerability」其實不是同一件事情。
尤其 Product Security 很常面對一個現實問題：當漏洞資訊公開時，如果 Security Update 還沒有準備好，User 到底可以做什麼？
因此 Disclosure Timing 本身，其實也是 Vulnerability Risk Management 的一部分。

七、CRA 其實有要求公開「已修正的漏洞資訊」
CRA Annex I Part II 有一項我覺得很值得注意的要求：在 Security Update 已經提供之後，Manufacturer 原則上應分享並公開 Fixed Vulnerability 的相關資訊，包括 Vulnerability Description、Affected Product Identification、Impact、Severity，以及協助 User Remediate 的清楚資訊。
研究到這裡時，我第一個想到的就是很多科技公司現在已經在做的 Product Security Advisory。
也就是在官方網站建立 Security Advisory 或 Product Security 頁面，當某項 Vulnerability 已完成處理並有 Security Update 或 Mitigation 可以提供時，再透過 Advisory 告訴 Customer 哪些 Product 或 Version 受到影響、風險是什麼，以及應該採取什麼措施。
所以我現在會把 Security Advisory 看成 CVD 與 Vulnerability Handling 流程最後很重要的一個 External Communication Output。

八、但公開時間也不是完全沒有彈性
CRA Annex I Part II 同時也保留了一個我覺得很實際的考量。
在有充分理由的情況下，如果 Manufacturer 認為公開 Fixed Vulnerability Information 所造成的 Security Risk，大於公開資訊本身帶來的 Security Benefit，可以延後公開，直到 User 已經有合理機會套用相關 Patch。
這對我而言其實非常符合 CVD 的精神。
不是「越快公開越好」，也不是「不要公開最好」，而是：
Disclosure 本身也需要做 Risk-based Decision。
有時候保護 User 的方式不是第一時間把所有 Technical Details 放上網，而是先讓 Patch、Mitigation 與 Customer Communication 到位，再進行適當程度的 Public Disclosure。

九、那是不是每個漏洞都一定要申請 CVE？
這題我自己會比較保守。
CRA Annex I 要求 Manufacturer 識別、記錄、處理與 Remediate Vulnerabilities，也要求在適當條件下 Disclosure Fixed Vulnerability Information。但從 CRA 條文本身，我目前不會直接解讀成：
「每一個 Vulnerability 都強制必須取得 CVE ID。」
CVE 是非常成熟而且很有價值的 Vulnerability Identification Mechanism。企業可以自己成為 CNA（CVE Numbering Authority），也可以透過適當的 CNA 申請 CVE，但 CRA Compliance Requirement 與 CVE Assignment，我自己還是會分開來看。
CVE 可以是 Vulnerability Management 很重要的一項工具，但不代表兩者完全畫上等號。

十、所以 CVE 比較像「漏洞的共同識別碼」
假設 Manufacturer 發布一份 Security Advisory，編號叫做 WB-2026-001，Customer 的 Vulnerability Scanner 使用另一個名稱，Supplier 的 Advisory 又有自己的編號，大家在 Supply Chain 裡很容易雞同鴨講。
如果這些資訊都可以指向同一個 CVE-2026-XXXXX，跨組織之間就比較容易確認：「我們現在談的是不是同一個 Vulnerability？」
因此 CVE 對 Vulnerability Ecosystem、Threat Intelligence、Scanner、SBOM、VEX 與 Supply Chain Communication 都非常有價值。
但我不會反過來說：
「沒有 CVE，就一定不符合 CRA。」
至少這不是我目前從 CRA 條文本身得到的理解。

十一、Article 14 Reporting 跟 Public Disclosure 更不能畫等號
這個地方我覺得特別需要區分。
假設 Manufacturer 發現一個 Actively Exploited Vulnerability，符合 CRA Article 14 的通報條件，那麼 Manufacturer 可能需要依規定向 CRA Single Reporting Platform 進行 Regulatory Reporting。
但這並不表示：
完成 24 小時 Early Warning 後，就必須把完整 Exploit Details 公開在公司官網。
因為 Regulatory Reporting 跟 Public Disclosure 的目的本來就不完全相同。前者是在符合條件時履行法規上的 Notification Obligation；後者則需要考量 User Protection、Patch Availability、Mitigation、Disclosure Risk，以及資訊公開後是否可能增加 Exploitation Risk。
CRA 對 Notification Information 的 Dissemination 也有另外的安排，在特定情況下可以基於 Cybersecurity-related Grounds 延後相關資訊的 Dissemination；2026 年生效的 Commission Delegated Regulation (EU) 2026/881 也進一步規範相關條件。
所以這裡我自己會特別在內部流程上寫清楚：
Regulatory Reporting ≠ Public Disclosure。

十二、但對受影響 User，CRA 又有另外的要求
CRA Article 14(8) 又是另一條 Communication Line。
當 Manufacturer 知悉 Actively Exploited Vulnerability 或 Severe Incident 後，還涉及對 Impacted Users 的通知，並在適當情況下通知 All Users，說明 Vulnerability 或 Incident，以及必要時 User 可以採取哪些 Risk Mitigation 或 Corrective Measures。
因此研究到這裡，我開始覺得 Product Security Incident 發生之後，至少有三種很容易被混在一起的 Communication：Regulatory Reporting、User Notification，以及 Public Security Advisory。
三者可能來自同一個 Vulnerability Case，但它們的 Trigger、Timing、Audience 與 Content 不一定完全相同。
這也是為什麼我覺得不能只做一張「漏洞通報表」，然後期待它解決所有問題。

十三、如果是 Semiconductor，User Notification 可能又更麻煩
這件事放到 Semiconductor Supply Chain，我覺得會更有意思。
假設 Semiconductor Manufacturer 賣一顆 MCU 給 OEM，OEM 把它做成 ECU，ECU 再提供給 Vehicle Manufacturer，最後整台 Vehicle 才交到 End User 手上。
如果今天 MCU 發現 Security Vulnerability，那誰是需要被通知的 User？哪些 Direct Customer 受到影響？Manufacturer 是否能直接識別最終受到影響的人？還是必須透過 Supply Chain 一層一層往下傳遞？
這些問題在 Semiconductor、Component 或 B2B Product 的情境下，可能會比一般 Consumer Software 複雜很多。
所以我自己會希望 Product、Sales、Customer Support / FAE 在 PSIRT Flow 裡也要有角色，因為 Security Team 可以判斷 Vulnerability，但不一定知道 Product 實際賣給哪些 Customer，更不一定掌握 Customer 最後把 Component 用在哪一個 End Product。
這也是 Product Security 很容易從「技術問題」一路走到「跨部門治理問題」的地方。

十四、我現在會把幾件事情刻意分開管理
做到這裡，我自己會刻意把幾個很容易混在一起的概念拆開來看。
CVD 解決的是外部如何安全地把 Vulnerability 告訴 Manufacturer，以及雙方如何協調後續處理與 Disclosure；Article 14 Reporting 解決的是符合 CRA 規定條件時，Manufacturer 如何履行 Regulatory Reporting Obligation；User Notification 關心的是受到影響的 User 需要知道什麼，以及可以採取哪些 Mitigation 或 Corrective Measures；而 Security Advisory / Public Disclosure 則比較偏向 Manufacturer 如何對外公開已修正 Vulnerability、Affected Products、Impact、Severity 與處理方式。
至於 CVE，我目前比較傾向把它看成支援 Vulnerability Identification 與 Ecosystem Communication 的共同識別機制，而不是把它直接等同於 CRA 的 Disclosure Requirement。
這只是我自己在 CRA 導入過程中整理思緒的方式，並不是 CRA 官方提供的分類方式。但這樣拆開之後，我自己在設計流程時清楚很多，也比較不會把「通報 EU」、「通知 Customer」、「發布 Security Advisory」與「申請 CVE」全部塞進同一個動作裡。

十五、如果讓我畫一條 Vulnerability Disclosure Flow
如果今天要先畫一個比較簡單的 End-to-End Flow，我自己可能會從 Vulnerability Report Received 開始，接著進行 Acknowledge / Triage、Validate & Reproduce、Affected Product Analysis，並在適當階段進行 Article 14 Assessment。
確認漏洞與受影響範圍後，再進入 Fix / Mitigation Development，同時持續與 Reporter 或相關利害關係人協調 Disclosure Timing。等 Security Update 或 Mitigation 已經準備到一定程度後，再視實際情況進行 User Notification、Security Advisory 與 Public Disclosure，最後完成 Case Closure。如果這個 Vulnerability 適合申請 CVE，也可以在流程中的適當階段加入 CVE Assignment。
這樣整理之後，我自己比較容易看出哪些階段屬於 Technical Response，哪些屬於 Regulatory Reporting，哪些又屬於 External Communication。
而真正困難的地方，往往不是流程圖畫不出來，而是每一個 Decision Point 到底由誰決定，以及當 Article 14 的 24 小時開始倒數時，這些人能不能真的找得到。

Day 11 小結｜Disclosure 對我來說，不只是「要不要公布漏洞」
研究到這裡，我自己對 Vulnerability Disclosure 最大的理解變化，就是它並不是「公開」或「不公開」這麼簡單的二選一問題。
真正需要處理的是：誰發現 Vulnerability、要怎麼通知 Manufacturer、Manufacturer 收到之後由誰回應、怎麼確認 Affected Products、什麼時候提供 Fix、是否觸發 Article 14、哪些 User 需要通知、什麼時候適合 Public Disclosure，以及是否需要 CVE。
這些事情串在一起，其實才是一整套 Coordinated Vulnerability Disclosure Process。
而 CRA 帶給我的另一個感受是，它不只是要求 Manufacturer 被動地「有人報漏洞就處理」，而是開始要求企業建立 CVD Policy、Single Point of Contact、Vulnerability Handling Process，以及 Fixed Vulnerability Information 的適當公開機制。
對我而言，這也是 CRA 很重要的一個轉變：
Product Security 不只發生在 R&D 裡，也開始需要對外建立一套可以被 Researcher、Customer 與 User 信任的 Vulnerability Communication Mechanism。
以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。實際的 Disclosure Timing、CVE Assignment、User Notification 與 Article 14 Reporting，還是需要依事件事實、Product Risk、CRA 正式要求及最新 Guidance 個別判斷。

Day 12 預告｜漏洞要維護多久？CRA 的 Support Period 為什麼不只是「保固期」？
漏洞處理流程建立之後，下一題很自然就是：
Manufacturer 到底要處理多久？
CRA 裡常看到一個很重要的概念：Support Period。
是不是一律五年？如果 Product Life 只有三年，也一定要支援五年嗎？如果 Industrial Product 可能被 Customer 使用十五年，Manufacturer 支援五年就可以了嗎？Support Period 跟 Warranty Period 是不是同一件事？Security Update 又需要免費提供多久？
更有意思的是，如果今天不是一套 Consumer Software，而是一顆可能被 Customer 放進設備裡使用十年以上的 Semiconductor，Support Period 又該怎麼思考？
Day 12，我們就來聊：
CRA Support Period、Security Update 與 Product Lifecycle。